home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / html / rfc / rfcxxxx / rfc1677 < prev    next >
Text File  |  1995-07-26  |  24KB  |  508 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         B. Adamson
  8. Request for Comments: 1677                     Naval Research Laboratory
  9. Category: Informational                                      August 1994
  10.  
  11.  
  12.       Tactical Radio Frequency Communication Requirments for IPng
  13.  
  14. Status of this Memo
  15.  
  16.    This memo provides information for the Internet community.  This memo
  17.    does not specify an Internet standard of any kind.  Distribution of
  18.    this memo is unlimited.
  19.  
  20. Abstract
  21.  
  22.    This document was submitted to the IETF IPng area in response to RFC
  23.    1550.  Publication of this document does not imply acceptance by the
  24.    IPng area of any ideas expressed within.  Comments should be
  25.    submitted to the big-internet@munnari.oz.au mailing list.
  26.  
  27. Executive Summary
  28.  
  29.    The U.S. Navy has several efforts exploring the applicability of
  30.    commercial internetworking technology to tactical RF networks.  Some
  31.    these include the NATO Communication System Network Interoperability
  32.    (CSNI) project, the Naval Research Laboratory Data/Voice Integration
  33.    Advanced Technology Demonstration (D/V ATD), and the Navy
  34.    Communication Support System (CSS) architecture development.
  35.  
  36.    Critical requirements have been identified for security, mobility,
  37.    real-time data delivery applications, multicast, and quality-of-
  38.    service and policy based routing.  Address scaling for Navy
  39.    application of internet technology will include potentially very
  40.    large numbers of local (intra-platform) distributed information and
  41.    weapons systems and a smaller number of nodes requiring global
  42.    connectivity.  The flexibility of the current Internet Protocol (IP)
  43.    for supporting widely different communication media should be
  44.    preserved to meet the needs of the highly heterogeneous networks of
  45.    the tactical environment.  Compact protocol headers are necessary for
  46.    efficient data transfer on the relatively-low throughput RF systems.
  47.    Mechanisms which can  enhance the effectiveness of an internet
  48.    datagram protocol to provide resource reservation, priority, and
  49.    service quality guarantees are also very important.  The broadcast
  50.    nature of many RF networks and the need for broad dissemination of
  51.    information to warfighting participants makes multicast the general
  52.    case for information flow in the tactical environment.
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Adamson                                                         [Page 1]
  59.  
  60. RFC 1677             IPng Tactical RF Requirements           August 1994
  61.  
  62.  
  63. Background
  64.  
  65.    This paper describes requirements for Internet Protocol next
  66.    generation (IPng) candidates with respect to their application to
  67.    military tactical radio frequency (RF) communication networks.  The
  68.    foundation for these requirements are experiences in the NATO
  69.    Communication System Network Interoperability (CSNI) project, the
  70.    Naval Research Laboratory Data/Voice Integration Advanced Technology
  71.    Demonstration (D/V ATD), and the Navy Communication Support System
  72.    (CSS) architecture development.
  73.  
  74.    The goal of the CSNI project is to apply internetworking technology
  75.    to facilitate multi-national interoperability for typical military
  76.    communication applications (e.g., electronic messaging, tactical data
  77.    exchange, and digital voice) on typical tactical RF communication
  78.    links and networks.  The International Standard Organization (ISO)
  79.    Open Systems Interconnect (OSI) protocol suite, including the
  80.    Connectionless Network Protocol (CLNP), was selected for this project
  81.    for policy reasons.  This paper will address design issues
  82.    encountered in meeting the project goals with this particular
  83.    protocol stack.
  84.  
  85.    The D/V ATD is focused on demonstrating  a survivable, self-
  86.    configuring, self-recovering RF subnetwork technology capable of
  87.    simultaneously supporting data delivery, including message transfer,
  88.    imagery, and tactical data, and real-time digital voice applications.
  89.    Support for real-time interactive communication applications was
  90.    extended to include a "white board" and other similar applications.
  91.    IP datagram delivery is also planned as part of this demonstration
  92.    system.
  93.  
  94.    The CSS architecture will provide U.S. Navy tactical platforms with a
  95.    broad array of user-transparent voice and data information exchange
  96.    services.  This will include support for sharing and management of
  97.    limited platform communication resources among multiple warfighting
  98.    communities.  Emphasis is placed on attaining interoperability with
  99.    other military services and foreign allies.  Utilization of
  100.    commercial off-the-shelf communications products to take advantage of
  101.    existing economies of scale is important to make any resulting system
  102.    design affordable.  It is anticipated that open, voluntary standards,
  103.    and flexible communication protocols, such as IP, will play a key
  104.    role in meeting the goals of this architecture.
  105.  
  106. Introduction
  107.  
  108.    Before addressing any IPng requirements as applied to tactical RF
  109.    communications, it is necessary to define what this paper means by
  110.    "IPng requirements".  To maintain brevity, this paper will focus on
  111.  
  112.  
  113.  
  114. Adamson                                                         [Page 2]
  115.  
  116. RFC 1677             IPng Tactical RF Requirements           August 1994
  117.  
  118.  
  119.    criteria related specifically to the design of an OSI model's Layer 3
  120.    protocol format and a few other areas suggested by RFC 1550.  There
  121.    are several additional areas of concern in applying internetwork
  122.    protocols to the military tactical RF setting including routing
  123.    protocol design, address assignment, network management, and resource
  124.    management.  While these areas are equally important, this paper will
  125.    attempt to satisfy the purpose of RFC 1550 and address issues more
  126.    directly applicable to selection of an IPng candidate.
  127.  
  128. Scaling
  129.  
  130.    The projection given in RFC 1550 that IPng should be able to deal
  131.    with 10 to the 12th nodes is more than adequate in the face of
  132.    military requirements.  More important is that it is possible to
  133.    assign addresses efficiently.  For example, although a military
  134.    platform may have a relatively small number of nodes with
  135.    requirements to communicate with a larger, global infrastructure,
  136.    there will likely be applications of IPng to management and control
  137.    of distributed systems (e.g., specific radio communications equipment
  138.    and processors, weapons systems, etc.) within the platform.  This
  139.    local expansion of address space requirements may not necessarily
  140.    need to be solved by "sheer numbers" of globally-unique addresses but
  141.    perhaps by alternate delimitation of addressing to differentiate
  142.    between globally-unique and locally-unique addressing.  The
  143.    advantages of a compact internet address header are clear for
  144.    relatively low capacity RF networks.
  145.  
  146. Timescale, Transition and Deployment
  147.  
  148.    The U.S. Navy and other services are only recently (the last few
  149.    years) beginning to design and deploy systems utilizing open systems
  150.    internetworking technology.  From this point of view, the time scale
  151.    for selection of IPng must be somewhat rapid.  Otherwise, two
  152.    transition phases will need to be suffered, 1) the move from unique,
  153.    "stove pipe" systems to open, internetworked (e.g., IP) systems, and
  154.    then 2) a transition from deployed IP-based systems to IPng.  In some
  155.    sense, if an IPng is quickly accepted and widely implemented, the
  156.    transition for tactical military systems will be somewhat easier than
  157.    the enterprise Internet where a large investment in current IP
  158.    already exists.  However, having said this, the Department of Defense
  159.    as a whole already deploys a large number  of IP-capable systems, and
  160.    the issue of transition from IP to IPng remains significant.
  161.  
  162. Security
  163.  
  164.    As with any military system, information security, including
  165.    confidentiality and authenticity of data, is of paramount importance.
  166.    With regards to IPng, network layer security mechanisms for tactical
  167.  
  168.  
  169.  
  170. Adamson                                                         [Page 3]
  171.  
  172. RFC 1677             IPng Tactical RF Requirements           August 1994
  173.  
  174.  
  175.    RF networks generally important for authentication purposes,
  176.    including routing protocol authentication, source authentication, and
  177.    user network access control.  Concerns for denial of service attacks,
  178.    traffic analysis monitoring, etc., usually dictate that tactical RF
  179.    communication networks provide link layer security mechanisms.
  180.    Compartmentalization and multiple levels of security for different
  181.    users of common communication resources call for additional security
  182.    mechanisms at the transport layer or above.  In the typical tactical
  183.    RF environment, network layer confidentiality and, in some cases,
  184.    even authentication becomes redundant with these other security
  185.    mechanisms.
  186.  
  187.    The need for network layer security mechanisms becomes more critical
  188.    when the military utilizes commercial telecommunications systems or
  189.    has tactical systems inter-connected with commercial internets.
  190.    While the Network Encryption Server (NES) works in this role today,
  191.    there is a desire for a more integrated, higher performance solution
  192.    in the future.  Thus, to meet the military requirement for
  193.    confidentiality and authentication, an IPng candidate must be capable
  194.    of operating in a secure manner when necessary, but also allow for
  195.    efficient operation on low-throughput RF links when other security
  196.    mechanisms are already in place.
  197.  
  198.    In either of these cases, key management is extremely important.
  199.    Ideally, a common key management system could be used to provide key
  200.    distribution for security mechanisms at any layer from the
  201.    application to the link layer.  As a result, it is anticipated,
  202.    however, that key distribution is a function of management, and
  203.    should not dependent upon a particular IPng protocol format.
  204.  
  205. Mobility
  206.  
  207.    The definition of most tactical systems include mobility in some
  208.    form.  Many tactical RF network designs provide means for members to
  209.    join and leave particular RF subnets as their position changes.  For
  210.    example, as a platform moves out of the RF line-of-sight (LOS) range,
  211.    it may switch from a typical LOS RF media such as the ultra-high
  212.    frequency (UHF) band to a long-haul RF media such as high frequency
  213.    (HF) or satellite communication (SATCOM).
  214.  
  215.    In some cases, such as the D/V ATD network, the RF subnet will
  216.    perform its own routing and management of this dynamic topology.
  217.    This will be invisible to the internet protocol except for
  218.    (hopefully) subtle changes to some routing metrics (e.g., more or
  219.    less delay to reach a host).  In this instance, the RF subnetwork
  220.    protocols serve as a buffer to the internet routing protocols and
  221.    IPng will not need to be too concerned with mobility.
  222.  
  223.  
  224.  
  225.  
  226. Adamson                                                         [Page 4]
  227.  
  228. RFC 1677             IPng Tactical RF Requirements           August 1994
  229.  
  230.  
  231.    In other cases, however, the platform may make a dramatic change in
  232.    position and require a major change in internet routing.  IPng must
  233.    be able to support this situation.  It is recognized that an internet
  234.    protocol may not be able to cope with large, rapid changes in
  235.    topology.  Efforts will be made to minimize the frequency of this in
  236.    a tactical RF communication architecture, but there are instances
  237.    when a major change in topology is required.
  238.  
  239.    Furthermore, it should be realized that mobility in the tactical
  240.    setting is not limited to individual nodes moving about, but that, in
  241.    some cases, entire subnetworks may be moving.  An example of this is
  242.    a Navy ship with multiple LANs on board, moving through the domains
  243.    of different RF networks.  In some cases, the RF subnet will be
  244.    moving, as in the case of an aircraft strike force, or Navy
  245.    battlegroup.
  246.  
  247. Flows and Resource Reservation
  248.  
  249.    The tactical military has very real requirements for multi-media
  250.    services across its shared and inter-connected RF networks.  This
  251.    includes applications from digital secure voice integrated with
  252.    applications such as "white boards" and position reporting for
  253.    mission planning purposes to low-latency, high priority tactical data
  254.    messages (target detection, identification, location and heading
  255.    information).  Because of the limited capacity of tactical RF
  256.    networks, resource reservation is extremely important to control
  257.    access to these valuable resources.  Resource reservation can play a
  258.    role in "congestion avoidance" for these limited resources as well as
  259.    ensuring that quality-of-service data delivery requirements are met
  260.    for multi-media communication.
  261.  
  262.    Note there is more required here than can be met by simple quality-
  263.    of-service (QoS) based path selection and subsequent source-routing
  264.    to get real-time data such as voice delivered.  For example, to
  265.    support digital voice in the CSNI project, a call setup and resource
  266.    reservation protocol was designed.  It was determined that the QoS
  267.    mechanisms provided by the CLNP specification were not sufficient for
  268.    our voice application path selection.  Voice calls could not be
  269.    routed and resources reserved based on any single QoS parameter
  270.    (e.g., delay, capacity, etc.) alone.  Some RF subnets in the CSNI
  271.    test bed simply did not have the capability to support voice calls.
  272.    To perform resource reservation for the voice calls, the CLNP cost
  273.    metric was "hijacked" as essentially a Type of Service identifier to
  274.    let the router know which datagrams were associated with a voice
  275.    call.  The cost metric, concatenated with the source and destination
  276.    addresses were used to form a unique identifier for voice calls in
  277.    the router and subnet state tables.  Voice call paths were to be
  278.    selected by the router (i.e. the "cost" metric was calculated) as a
  279.  
  280.  
  281.  
  282. Adamson                                                         [Page 5]
  283.  
  284. RFC 1677             IPng Tactical RF Requirements           August 1994
  285.  
  286.  
  287.    rule-based function of each subnet's capability to support voice, its
  288.    delay, and its capacity.  While source routing provided a possible
  289.    means for voice datagrams to find their way from router to router,
  290.    the network address alone was not explicit enough to direct the data
  291.    to the correct interface, particularly in cases where there were
  292.    multiple communication media interconnecting two routers along the
  293.    path.  Fortunately, exclusive use of the cost QoS indicator for voice
  294.    in CSNI was able to serve as a flag to the router for packets
  295.    requiring special handling.
  296.  
  297.    While a simple Type of Service field as part of an IPng protocol can
  298.    serve this purpose where there are a limited number of well known
  299.    services (CSNI has a single special service - 2400 bps digital
  300.    voice), a more general technique such as RSVP's Flow Specification
  301.    can support a larger set of such services.  And a field, such as the
  302.    one sometimes referred to as a Flow Identification (Flow ID), can
  303.    play an important role in facilitating inter-networked data
  304.    communication over these limited capacity networks.
  305.  
  306.    For example, the D/V ATD RF sub-network provides support for both
  307.    connectionless datagram delivery and virtual circuit connectivity.
  308.    To utilize this capability, an IPng could establish a virtual circuit
  309.    connection across this RF subnetwork which meets the requirements of
  310.    an RSVP Flow Specification. By creating an association between a
  311.    particular Flow ID and the subnetwork header identifying the
  312.    established virtual circuit, an IPng gateway could forward data
  313.    across the low-capacity while removing most, if not all, of the IPng
  314.    packet header information.  The receiving gateway could re- construct
  315.    these fields based on the Flow Specification of the particular Flow
  316.    ID/virtual circuit association.
  317.  
  318.    In summary, a field such as a Flow Identification can serve at least
  319.    two important purposes:
  320.  
  321.          1)      It can be used by routers (or gateways) to identify
  322.                  packets with special, or pre-arranged delivery
  323.                  requirements.  It is important to realize that it may
  324.                  not always be possible to "peek" at internet packet
  325.                  content for this information if certain security
  326.                  considerations are met (e.g., an encrypted transport
  327.                  layer).
  328.  
  329.          2)      It can aid mapping datagram services to different
  330.                  types of communication services provided by
  331.                  specialized subnet/data link layer protocols.
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Adamson                                                         [Page 6]
  339.  
  340. RFC 1677             IPng Tactical RF Requirements           August 1994
  341.  
  342.  
  343. Multicast
  344.  
  345.    Tactical military communication has a very clear requirement for
  346.    multicast.  Efficient dissemination of information to distributed
  347.    warfighting participants can be the key to success in a battle.  In
  348.    modern warfare, this information includes imagery, the "tactical
  349.    scene" via tactical data messages, messaging information, and real-
  350.    time interactive applications such as digital secure voice.  Many of
  351.    the tactical RF communication media are broadcast by nature, and
  352.    multicast routing can take advantage of this topology to distribute
  353.    critical data to a large number of participants.  The throughput
  354.    limitations imposed by these RF media and the physics of potential
  355.    electronic counter measures (ECM) dictate that this information be
  356.    distributed efficiently.  A multicast architecture is the general
  357.    case for information flow in a tactical internetwork.
  358.  
  359. Quality of Service and Policy-Based Routing
  360.  
  361.    Quality of service and policy based routing are of particular
  362.    importance in a tactical environment with limited communication
  363.    resources, limited bandwidth, and possible degradation and/or denial
  364.    of service.  Priority is a very important criteria in the tactical
  365.    setting.  In the tactical RF world of limited resources (limited
  366.    bandwidth, radio assets, etc.) there will be instances when there is
  367.    not sufficient capacity to provide all users with their perception of
  368.    required communication capability.  It is extremely important for a
  369.    shared, automated communication system to delegate capacity higher
  370.    priority users.  Unlike the commercial world, where everyone has a
  371.    more equal footing, it is possible in the military environment to
  372.    assign priority to users or even individual datagrams.  An example of
  373.    this is the tactical data exchange.  Tactical data messages are
  374.    generally single-datagram messages containing information on the
  375.    location, bearing, identification, etc., of entities detected by
  376.    sensors.  In CSNI, tactical data messages were assigned 15 different
  377.    levels of CLNP priority.  This ensured that important messages, such
  378.    as a rapidly approaching enemy missile's trajectory, were given
  379.    priority over less important messages, such as a friendly, slow-
  380.    moving tanker's heading.
  381.  
  382. Applicability
  383.  
  384.    There will be a significant amount of applicability to tactical RF
  385.    networks.  The current IP and CLNP protocols are being given
  386.    considerable attention in the tactical RF community as a means to
  387.    provide communication interoperability across a large set of
  388.    heterogeneous RF networks in use by different services and countries.
  389.    The applicability of IPng can only improve with the inclusion of
  390.    features critical to supporting QoS and Policy based routing,
  391.  
  392.  
  393.  
  394. Adamson                                                         [Page 7]
  395.  
  396. RFC 1677             IPng Tactical RF Requirements           August 1994
  397.  
  398.  
  399.    security, real-time multi-media data delivery, and extended
  400.    addressing.  It must be noted that it is very important that the IPng
  401.    protocol headers not grow overly large.  There is a sharp tradeoff
  402.    between the value added by these headers (interoperability, global
  403.    addressing, etc.) and the degree of communication performance
  404.    attainable on limited capacity RF networks.  Regardless of the data
  405.    rate that future RF networks will be capable of supporting, there is
  406.    always a tactical advantage in utilizing your resources more
  407.    efficiently.
  408.  
  409. Datagram Service
  410.  
  411.    The datagram service paradigm provides many useful features for
  412.    tactical communication networks.  The "memory" provided by datagram
  413.    headers, provides an inherent amount of survivability essential to
  414.    the dynamics of the tactical communication environment.  The
  415.    availability of platforms for routing and relaying is never 100%
  416.    certain in a tactical scenario.  The efficiency with which multi-cast
  417.    can be implemented in a connectionless network is highly critical in
  418.    the tactical environment where rapid, efficient information
  419.    dissemination can be a deciding factor.  And, as has been proven,
  420.    with several different Internet applications and experiments, a
  421.    datagram service is capable of providing useful connection-oriented
  422.    and real-time communication services.
  423.  
  424.    Consideration should be given in IPng to how it can co-exist with
  425.    other architectures such as switching fabrics which offer demand-
  426.    based control over topology and connectivity.  The military owns many
  427.    of its own communication resources and one of the large problems in
  428.    managing the military communication infrastructure is directing those
  429.    underlying resources to where they are needed.  Traditional
  430.    management (SNMP, etc.) is of course useful here, but RF
  431.    communication media can be somewhat dynamically allocated.  Circuit
  432.    switching designs offer some advantages here.  Dial-up IP routing is
  433.    an example of an integrated solution.  The IPng should be capable of
  434.    supporting a similar type of operation.
  435.  
  436. Support of Communication Media
  437.  
  438.    The tactical communication environment includes a very broad spectrum
  439.    of communication media from shipboard fiber-optic LANs to very low
  440.    data rate (<2400 bps) RF links.  Many of the RF links, even higher
  441.    speed ones, can exhibit error statistics not necessarily well-
  442.    serviced by higher layer reliable protocols (i.e., TCP).  In these
  443.    cases, efficient lower layer protocols can be implemented to provide
  444.    reliable datagram delivery at the link layer, but at the cost of
  445.    highly variable delay performance.
  446.  
  447.  
  448.  
  449.  
  450. Adamson                                                         [Page 8]
  451.  
  452. RFC 1677             IPng Tactical RF Requirements           August 1994
  453.  
  454.  
  455.    It is also important to recognize that RF communication cannot be
  456.    viewed from the IPng designer as simple point-to-point  links.
  457.    Often, highly complex, unique subnetwork protocols are utilized to
  458.    meet requirements of survivability, communications performance with
  459.    limited bandwidth, anti- jam and/or low probability of detection
  460.    requirements.  In some of these cases IPng will be one of several
  461.    Layer 3 protocols sharing the subnetwork.
  462.  
  463.    It is understood that IPng cannot be the panacea of Layer 3
  464.    protocols, particularly when it comes to providing special mechanisms
  465.    to support the endangered-specie low data rate user.  However, note
  466.    that there are many valuable low data rate applications useful to the
  467.    tactical user.  And low user data rates, coupled with efficient
  468.    networking protocols can allow many more users share limited RF
  469.    bandwidth.  As a result, any mechanisms which facilitate compression
  470.    of network headers can be considered highly valuable in an IPng
  471.    candidate.
  472.  
  473. Security Considerations
  474.  
  475.    Security issues are discussed throughout this memo.
  476.  
  477. Author's Address
  478.  
  479.    R. Brian Adamson
  480.    Communication Systems Branch
  481.    Information Technology Division
  482.    Naval Research Laboratory
  483.    NRL Code 5523
  484.    Washington, DC 20375
  485.  
  486.    EMail: adamson@itd.nrl.navy.mil
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Adamson                                                         [Page 9]
  507.  
  508.